> Obviously, the *temporary solution* as stated on Netscape's page is > to disable client access via xhost, however it bugs me that Netscape > can be controlled remotely. That's the price you pay for running binary-only commercial software, you get what the software vendor chooses to give you. > This ''feature'' by Netscap seems utterly pointless, since to have a > web server control your netscape you would have to disable security > (xhost +) or manually add the site to the access control list, > assuming that the site is ''safe''. Yeah, to have a web server control the browser, that's true. I don't think the intended client of this protocol is the web server; more likely, it's intended for other local programs. For example, one could use it to run canned demos by having a process sitting around pushing netscape from page to page in a pre-scripted manner, while netscape is positioned and sized so that nothing but the page itself is visible on the screen (borders and buttons and such are all off-screen). Or one could use it as someone else already suggested, so that you can click on a URL in an editor, or type it to a command-line tool, and have netscape show it. Or I'm sure there are plenty of other things one could do with it. It is a security problem, but not as large a one as some people seem to feel. Generally speaking, if your X display is open to a process, that process can do anything - and thus for normal use you don't want to run with your display open. However, if a process can connect to a display, it can't do anything that other clients on that display aren't capable of. This "feature" means that if you have a netscape running on that display, you have now opened up the filesystem of the machine netscape is running on. (If there are no xterms or any other client capable of shell access or writing to files, then the attacking client can disrupt the X session but nothing more.) der Mouse mouse@collatz.mcrcim.mcgill.edu